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Abstract 

Modem transportation consists of many unique modes of travel. Each of these modes and their 
respective industries has evolved independently over time, forming a largely incoherent and inefficient 
overall transportation system. Travelers today are forced to spend unnecessary time and efforts planning a 
trip through varying modes of travel each with their own scheduling, pricing, and services; causing many 
travelers to simply rely on their relatively inefficient and expensive personal automobile. This paper 
presents a demonstration program system to not only collect and format many different sources of trip 
planning information, but also combine these independent modes of travel in order to form optimal routes 
and itineraries of travel. The results of this system show a mean decrease in inter-city travel time of 
10 percent and a 25 percent reduction in carbon dioxide emissions over personal automobiles. 
Additionally, a 55 percent reduction in carbon dioxide emissions is observed for intra-city travel. A 
conclusion is that current resources are available, if somewhat hidden, to drastically improve point to 
point transportation in terms of time spent traveling, the cost of travel, and the ecological impact of a trip. 
Finally, future concepts are considered which could dramatically improve the interoperability and 
efficiency of the transportation infrastructure. 

Nomenclature 

API Application Programming Interface 

FA A Federal Aviation Administration 

GUI Graphical User Interface 

GPS Global Positioning System 


Introduction 

Public transportation around the United States is underutilized compared to other developed parts of 
the world. In Europe, public transportation accounts for over 50 percent of trips within large cities as 
opposed to about 20 percent in the United States (Ref. 1). As shown in Figure 1, westernized, non- 
European countries often exhibit the largest percentage of personal automotive use. 

Instead the U.S. public utilizes personal automobiles as a primary means of transportation. Data from 
the Federal Highway Administration shows that traffic volumes have steadily increased over the past 
20 years. As traffic volumes increase, the impact on our environment increases as well. The 
Environmental Protection Agency estimates that the average U.S. passenger vehicle emits 5.5 metric 
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Figure 1 . — Average automotive use by country. Countries such as the United States, 
Australia, and Canada often maintain the highest percentage of personal automobile 
use per trips. European countries that focus more heavily on mass transportation 
maintain a lower percentage of automobile use per trip. Data range from 1994 to 2006. 


tons of carbon dioxide annually (Ref. 2). One of the principle reasons for the reliance on the personal 
automobile is that all of the public transportation systems in the US have evolved independently creating 
an inefficient system that is cumbersome for the public to use. This has resulted in a cultural dependence 
on automobile travel. The solution proposed by this report involves developing a real time mobile 
application to bring together all of the dissociated information from the various transportation systems 
into to one easy to use program that will optimize point-to-point travel based on three metrics: the 
duration of the trip, the cost of the trip, and the carbon footprint associated with the trip. 

A demonstration program has been developed for travel between New York City and 
Washington D.C. to illustrate how a system like the one described could work. The demonstration 
program uses public transportation systems that are currently in use to optimize point-to-point travel 
based on three metrics and compared the results to a baseline. The baseline for the program is personal 
automotive travel. A detailed analysis of the results is discussed later in this report. This work points to 
the need for the availability of more travel information including schedules, delays, cost, and other 
variables that can be used by program applications to optimize travel. 


Current Examples 

There are many examples of attempts at a full intermodal journey planner. Some examples include 
Google Transit (Google Inc.), PlymGo (Futurate), and Rome2Rio (Rome2rio Pty Ltd). Google Transit 
uses a variety of modes of transportation, especially within major cities, to plan their journeys (Ref. 3). It 
has coverage throughout the world and since it is in beta testing, they are continually updating their 
information as more cities and services add themselves to the network. PlymGo is a service for the city of 
Plymouth, United Kingdom that compares the cost, time, and environmental impact of various modes of 
transportation from one point in the city to another (Ref. 4). It even includes the calories burned for 
modes such as walking and biking. Rome2Rio is the closest of the three to a complete intermodal journey 
planner in that it compares all modes of public transit; planes as well as limited trains and buses, and 
compares the time and cost between various routes calculated between two points (Ref. 5). 
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These are great services for what they can do, however, they all have limitations. One limitation that 
is common between them and all other journey planners is that people are for the most part unaware of 
these programs. Public awareness for planners such as these is low, especially outside major cities. Also, 
the number of websites, smart phone applications, and other forms of journey planners are growing but is 
nowhere near the level of automobile transportation. Additionally, they each have their own issues that 
prevent them from being complete world-wide intermodal journey planners. 

Google Transit does not have public transportation information for all cities, and is often limited in its 
calculations between major cities. It does not include air travel, nor does it include long distance bus 
routes through companies such as Greyhound (Greyhound Lines Inc.) or MegaBus (Stagecoach Group 
PLC). Also, it only accounts for travel time and does not consider any other metrics. Google Transit does 
not show the cost of the trip (or compare prices between different routes) nor does it show the carbon 
footprint of the various modes of transport. 

PlymGo is great in their metrics for comparison, but is limited to travel within the city of Plymouth. It 
also does not piece together routes, in that it will not tell a passenger to take a bus to a train station to 
finish the trip. Therefore, it is limited in its calculations. Rome2Rio compares flights all around the world; 
however, it does not do the same for ground public transportation. Currently its railway and bus route 
calculations are limited to Europe, China, and India. Like Google Transit, it also does not include a 
passenger’s carbon footprint into the comparisons. 

Another limitation for an intermodal journey planner is that there is an overabundance of information 
to handle. All around the world, flight, bus, train and other forms of transportation schedules are changing 
all the time to meet current demands. This adds an additional toll for journey planners in that they have to 
keep up with these changes in order to be accurate and useful. Another burden is adding real time data, 
such as GPS locations of buses and other similar vehicles. Handling all this information is challenging, 
which is why most intermodal planners are confined, like PlymGo, to a single city or region, where the 
scope is easier to manage. 

Another barrier is found in the airline companies themselves and their protection of flight 
information. Accessing this information tends to be expensive and complicated. This hinders competition 
and prevents new companies and agencies from flourishing. 

Metrics 

In order for an intermodal journey planner to be successful, it must provide the public with a readily 
available and easy to use interface that reports the desired information in a concise logical manner. One 
major complaint about public transportation is that is takes too long and too much time is spent idle. 
Another major factor for all modes of transportation is cost. Despite what people may claim, money will 
always be one of the major driving factors behind any decision, and transportation is no different. If using 
public transportation is not cost effective, people will not use it. 

The demonstration program is designed to optimize the desired travel route based on how long the 
traveler will spend en route to the destination, how much the trip will cost, and the environmental impact 
of the trip. The economic and temporal metrics were chosen because people want to arrive at their 
destination in the shortest amount of time for the least amount of money. The environmental impact was 
chosen as a third metric because society is becoming increasingly aware of their impact on the Earth and 
the possible long term repercussions that could result from over consumption of fossil fuels. 

The three metrics will be evaluated against a baseline of personal automotive travel within and 
between city centers. The user is able to select which metric is preferable. After the program evaluates the 
various possible transportation options against the baseline, it determines the best route according to the 
user’s preferences. 

The program makes a few assumptions when calculating the output values for each of the metrics. 

The duration of travel for automobiles is determined using Google Maps (Google Inc.) which uses the 
distance, speed limits, and real time traffic updates to estimate the travel time. The travel time while using 
public transportation is determined from the estimates given by the specific transportation agency’s 


NASA/TM— 20 12-2 17286 


3 



schedule. If air travel is used as one of the modes of transportation, the program assumes that the user will 
arrive at the airport 90 min prior to the scheduled departure (Ref. 6). The program determines the cost of 
the trip based on the economic information provided by the various airline companies and internet sites 
for the different public transportation systems. The cost of driving in a car is based on the government per 
diem rate of 5 1 cents per mile which is given to employees if they use their own vehicle for travel 
(Ref. 7). This estimate is based on average costs for fuel, maintenance, and other costs associated with 
owning a car. 

The environmental impact of the travel route is measured in pounds of carbon dioxide emitted into 
the atmosphere per passenger mile. Emission data from actual travel routes was used to determine an 
average amount of carbon dioxide emitted per passenger mile. This estimate is then multiplied by the 
travel distance to get the total amount of carbon dioxide emitted. 

Demonstration Code 

The sample code that was developed is intended to demonstrate the functionality of an intermodal 
transportation system. The code only focuses on transportation systems that are currently available to the 
public. Many future transportation concepts are discussed later on in this report; however, the code does 
not utilize any of these concepts because the goal was to demonstrate a fully functioning program for the 
regions that were chosen. Creating the code based on current transportation systems allows the use of 
existing information available on the internet such as routes and schedules for air travel between cities. 
Thus the code is a true representation of a potential final product. 

The cities chosen for the demonstration were New York City and Washington D.C. They were used 
because both have well developed public transportation systems, the distance between them is such that 
either driving or flying could be viable options depending on the user’s preferences, and both have 
significant traffic problems. Another reason for choosing these cities is that their public transportation 
systems have web based applications that allow computer programs to easily access real time information 
such as schedules, costs, and delays. Airlines, on the other hand, are lagging behind other forms of public 
transportation when it comes to openly sharing information over the internet. This could be partly due to 
security concerns. To mitigate this shortcoming, the research team constructed a statistical model of flight 
times, costs, and delays to emulate air travel. The emulator can be easily replaced with a true flight 
module once airlines are willing to make their information available. 

This ease of modification is due to the demonstration code’s object oriented architecture. Object 
oriented programming is a style of thought process where algorithms are arranged into self contained 
modules that each, independently, perform a task resulting in a particular output based on inputs. The user 
of a module does not need to understand how or why the particular module operates, but only how to 
interact with the module. These independent modules are then assembled in sequence to perform a task 
that is much more complex than the tasks performed individually. Additionally, these modules are not 
dedicated to one particular system. They may each be used in other system assemblies that perform 
different functions. 

For the demonstration system, object oriented programming offered the ability to easily integrate 
future classes of modes of transportation as well as update current classes of modes without the need to 
alter the operation of the other classes. To meet these criteria, the programming language of Python 2.6.6 
(Python Software Foundation) was used. The object oriented architecture is made more apparent by the 
system architecture shown in Figure 2. 

The three data parsing modules near the right represent the three current modes of transportation 
considered by the system. The flight data parser collects information on available flights between cities 
based on the routing information given by the route caller. Similarly, the automotive data parser collects 
information for driving routes. The public data parser considers resources already available through the 
internet. Namely, a service provided by Jeppesen Land Application Programming Interface (API) 
(Jeppesen Sanderson Inc.) that has taken public busing, light rail, subway, and water ferries into account 
(Ref. 8). Each one of these modules may be exchanged for a different data parser of the same name and 
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Figure 2. — A flowchart of the demonstration code process and modules. Each object in the flowchart relates to an 
independent program. Arrows represent the flow of information between the programs. Note that no global 
variables are used and that all data was exchanged on a one to one basis. Module programs only receive access 
to data necessary for their task. 


interface, without disrupting any of the other modules. Additionally, other modules may be added to the 
existing three to allow expanded functionality for new or updated modes of transportation. The only 
alteration needed would be to the route caller module to reference the new modules. The route caller 
automatically detects a new transit module when it is introduced and requested by the module manager. It 
then prompts the user that the router module may be out of date and require attention. 

The module management provides the basic user interface and general structuring of the class 
instances to perform the route optimization. Currently, the inter-modal demonstration system utilizes a 
simple, text based, input output interface. This may later be replaced by a graphical user interface (GUI) 
to improve user friendliness and appeal to the general public. 


Results 

After a sample set of 108 routes between 16 randomly chosen locations in each city, several trends 
became apparent. All routing information generated by the demonstration system was compared against 
the baseline of traveling along the fastest route, from Google Maps, by personal automobile. When 
performing inter-city travel, by optimizing for time, the sample code most frequently selected a route 
consisting of driving to the nearest airport, purchasing a flight to the destination city, and then renting a 
car or carpooling to the final destination. With this combination, there was a mean time savings of 
10 percent and a mean carbon emissions reduction of 19 percent. As the distance between the destination 
and departure cities increase, these values are expected to increase since the major time and carbon 
emission reduction is experienced during air travel. Therefore increasing the utilization of air travel will 
emphasize its time and emission saving effects. 

When optimizing a similar route for ecological impact, the mean carbon emissions could be reduced 
up to 25 percent, however a significant time penalty of between -73 and -83 percent was observed. A 
summary of the relevant observations is shown in Table 1. 

Notice that there was no improvement in cost optimization for any metrics. This is because the 
intermodal system almost always determined that driving individually was the least expensive option. As 
previously explained, this was due to the system only considering the cost of travel alone. This also 
means that the poor cost improvement metrics for time and carbon emissions optimization may not 
actually be representative of costly intermodal routes. 
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TABLE 1.— MEAN OBSERVED IMPROVEMENT FOR INTER-CITY TRAVEL 


Optimizing for. . . 

Cost, 

percent 

Time, 

percent 

Carbon emission, 
percent 

Minimum travel time 

-24 

10 

19 

Minimum trip cost 

0 

0 

0 

Minimum carbon emissions 

-27 

-73 

25 


All values listed are percent improvements over the baseline case of driving similar routes purely by 
personal automobile. Negative values are representative of the demonstration system not outputting a 
route that improved upon the baseline. Values of 0 are representative of automotive travel proving optimal 
for the preferred metric. 


TABLE 2.— MEAN OBSERVED IMPROVEMENT FOR INTRA-CITY TRAVEL 


Optimizing for. . . 

Cost, 

percent 

Time, 

percent 

Carbon emission, 
percent 

Minimum travel time 

0 

0 

0 

Minimum trip cost 

45 

-181 

55 

Minimum carbon emissions 

45 

-181 

55 


When performing intra-city travel and optimizing for ecological impact, the sample code always 
selected a route consisting of one or more legs of public transportation and displayed a mean carbon 
emission reduction of 55 percent over automotive travel. Also shown in Table 2, the sample code 
predicted a 45 percent reduction in travel cost. While optimizing for time, the sample code revealed that 
personal automotive travel was almost always the best option. 

Assumptions 

During the assembly of the demonstration code several assumptions were made in the interest of time, 
but can be easily modified to improve accuracy. The most relevant assumptions are outlined below. 

There is a flat 90 min wait time whenever the traveler employs air travel. This assumption is based on 
the current Federal Aviation Administration (FAA) recommendation to account for baggage check, ticket 
retrieval, security checks, and baggage claim (Ref. 6). Future iterations of the demonstration code, or an 
updated air data parser module, may provide real time information of wait times at various airports via 
information provided by the FAA delay time watcher located on their website. 

Carbon emissions are based on United States national averages of pounds of carbon dioxide per 
passenger mile for various modes of transportation (Ref. 9). Future revisions on the demonstration 
program could include actual emissions from the user’s vehicle. Additionally, since flights may be placed 
into holding patterns or rerouted due to weather, air travel emissions are based on “as the crow flies” 
distances summed with an additional 30 miles of departure and approach flight distance. Also, the sample 
code may instruct the user to walk if the routing distance does not exceed 1.25 miles (Ref. 10). Carbon 
emissions caused by human respiration are considered negligible compared to mechanized travel and are 
therefore disregarded. 

The sample code relies primarily upon the free information services of Google Maps and Jeppesen 
Land API for travel data collection. Both of these companies publish APIs online to distribute their 
information in a standardized form. However, both of these companies are continually updating and 
refining their information. This may lead to a change in their respective information publishing formats 
sometime in the future. The sample code has built in redundancies to first compensate for any changes in 
the API information formats, and when unable to compensate, alerts the user to the possibility that the 
sample code has fallen out of date and may need alterations or module replacement to continue operation. 

Special deals and travel rates are not considered in the sample code. Items such as promotional 
vouchers, senior or infant discounts, and/or frequent flier mileage are unique and specific to a particular 
traveler. Such items may be entered into the user interface in future iterations of the intermodal system, 
but were not considered. 
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Comparison to Current Systems 

A comparison of the code with current intermodal public transportation journey planners was 
necessary to assess the validity of the results and viability of the demonstration code. 

The demonstration code compares routes based on three metrics; time, cost and environmental impact. 
This is similar to PlymGo; however, the demonstration code has the advantage of including more than one 
city and also compares routes that use a variety of modes of transport. The code could potentially show that 
a route that uses a subway, an airplane, and a metro bus to be the most environmentally friendly trip 
possible. PlymGo is limited to trips by only one method of transportation (Ref. 4). 

Airlines tend to restrict access to their flight information until the point of sale. This poses a problem 
for our demonstration intermodal journey system which attempts to query the flight data for free and 
format it in a simple manner. To mitigate this, the code emulates airplane travel between John F. Kennedy 
International Airport in New York City and Dulles International Airport near Washington D.C. based on 
research conducted. Rome2Rio does include flight planning and compares numerous airlines. 

The demonstration code uses Jeppesen Land API to calculate the public transit routes within certain 
cities. As with most public transit journey planners, Jeppesen Land API has a limited data range (Ref. 8). 
It can only handle a few cities, but the number of cities included in its calculation is projected to grow in 
the future. As of now, it also only includes services within a city’s boundaries. For instance, Dulles 
International Airport is outside Jeppesen’s boundary for Washington D.C. Therefore, an emulation 
module was included into the demonstration code to get the passenger from Dulles Airport to 
Washington D.C. and back. This was done by using the time of the trip with the airport shuttle time table. 
As the range of Jeppesen’s calculations expands, this emulation will become unnecessary (Ref. 8). 

In order for the demonstration code to become more user friendly, a GUI is desired. The code, as of 
now, runs through a simple command prompt, but future versions and updates could allow it to be 
accessed through a website with buttons, scroll bars and other items that can help future travelers choose 
their routes and destinations easier. With no interface, the demonstration code falls far behind Google 
Transit, PlymGo and Rome2Rio in terms of user friendliness and usability. Other aspects missing from 
the demonstration code, such as route calculation for multiple passengers, can be added to update the code 
easily due to the object oriented nature of the code. 

Future Concepts 

Current social trends have led the information technology market to a state of hyper community. That 
is, personal and commercial information has become increasingly available for retrieval without 
significant cost to the searcher. To that end, several future attributes that may be added to the inter-modal 
transportation system have been considered. 

Current and future technologies offer increased access to real-time information while en route along 
an intermodal trip. Services such as Google Transit have already begun to collect information concerning 
traffic conditions, weather, construction, and public transit schedules and publishing them to the web via 
interactive GUIs and online APIs for little to no fee (Ref. 3). This information, coupled with user specific 
information gathered by personal smart phones and accessed portably through cellular service providers, 
could allow users of the inter-modal system to receive updated trip information en route in order to 
further optimize both individual and overall system performance. 

Consider the following hypothetical scenario. An airline flight is approaching its destination. On 
board are several dozen users of the intermodal system who have already searched for and scheduled their 
individual trips which include their current flight. In the destination city is a cab or bus service that has 
access to the arrival times of the intermodal system users. Upon noting that a large number of passengers 
will soon be arriving, the cab or bus service dispatches the appropriate number of vehicles to receive the 
passengers. Having known the proper number of vehicles to dispatch, the cab or bus service is able to 
maximize profit while minimizing losses due to underutilization. Furthermore, the users of the inter- 
modal system experience little to no layover time while waiting for an empty cab or bus to arrive, along 
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with knowing the exact fare that will be required. An automated billing system is could be developed that 
tracks the actual route and submits payment through the smart phone. This reduces a common anxiety for 
travelers using public transportation systems ( in terms of knowing how much to pay and the payment 
method). In this situation, the sharing of information played to the benefit of all parties involved and 
maximized the productivity of the system. 

The various aspects of the above scenario have not been overlooked by today’s transit services. Cities 
such as New York, London, and Plymouth have already implemented services to provide open 
information about the current state of public transportation systems in their respective jurisdictions. Open 
information meaning the free and easily accessible release of documentation to the general public. Each 
city has noted an increase in utilization of their public transit services since opening their information to 
the public, for instance London has seen a 65 percent increase in their bus usage alone (Ref. 1 1). As 
mentioned earlier, airline service providers have not kept pace. That is not to say that it is impossible to 
directly compare flights, but current providers of such services often charge a fee and do not openly 
distribute their information. 

One near term concept not included in the sample code that may be added is the concept of the next 
generation airspace system (NextGen). NextGen is the fundamental restructuring of the national airspace 
system to alleviate costs, delays, and the environmental impact while allowing for significant growth of 
the aviation industry (Ref. 12). Updating the national airspace system is crucial in order to sustain the 
expected growth rate of the aviation industry. Boeing, Airbus, and the FAA all predict the number of 
aircraft to nearly double in the next twenty years (Refs. 13 to 15). Many of the changes involve providing 
greater situational awareness through improved technology as well as streamlining aircraft ground 
operations and traffic patterns. The FAA predicts that by 2018 NextGen will reduce delays by 35 percent 
saving an estimated 1.4 billion gallons of aviation fuel and reduce carbon dioxide emissions by 14 million 
English tons (Ref. 12). 

Another proven technique to develop public transportation is open source information. Many public 
transit companies and agencies believe it is their responsibility to provide their routes and information to 
the public. However, due to lack of funding or bureaucracy, this tends to produce difficult to use 
interfaces and formats. If an agency were to simply provide the information, instead of attempting to 
format it themselves, third party developers could then use and manipulate it to make it easier for the 
public to use, at no cost to the agency. Third party developers can be more efficient and by open sourcing, 
agencies allow many more developers work with the data than they could provide themselves. 

An example case of open sourcing in action is through the Massachusetts Department of 
Transportation. In 2009 they open sourced their information and within days, there were numerous 
websites, applications and phone services. Within weeks, there were just as many different smart phone 
applications and other methods of providing public transit information to the populous (Ref. 16). One of 
these involved electronic signs above stores along bus routes. The signs showed when the bus would 
arrive at the nearest bus stop using real time data. Instead of waiting at the bus stop, a traveler can spend 
their time at a store or someplace more comfortable and still not miss their bus. The end result was better 
for the community. The Massachusetts Department of Transportation got their information out to the 
public at no cost and the public now has a large variety of ways to plan their trips by public 
transportation. 

It has been shown above that there are many benefits to sharing information openly; on the other hand 
there are some serious risks as well. Knowing specific details about the time and location of public 
transportation systems has shown to be quintessential to increasing the public use of intermodal 
transportation. However, releasing this information to the public poses a serious security threat. Terrorist 
organizations could use this information to carry out their attacks more effectively. This is one of the 
major issues the team was not able to explore and is beyond the scope of this study. Security must be 
considered if a wide spread intermodal transportation system is going to be implemented in the future. 

Another difficult aspect will be to encourage cooperation between the various transportation 
companies and agencies. In this competitive market, showing favoritism to one company or another 
would be tempting, but cannot be tolerated in order to achieve optimal routes and modes of travel. An 
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example of a competitive market system like this working together would be Transport for London. 
Transport for London is a government service that contracts with many bus, subway, and other 
transportation mode companies in order to provide one all encompassing service (Ref. 17). This allows 
for Transport for London to issue one ticket that is good for all the different transportation modes within 
the city and allows the passenger to travel from one point to another easily and efficiently. 

Several future modes of transportation were also considered for future implementation into an 
integrated intermodal transportation system. Among these future concepts was the proposed United States 
high speed rail network. This new rail network would include renovating and rating much of the current 
United States rail network for high speed travel as well as creating several new lines between many of the 
east coast cities (Ref. 18). Addition of this improved rail network could be manifested in the 
demonstration code through two unique forms. Firstly, the public transportation API provider, namely 
Jeppesen Land API, may choose to update their data base. In which case, no modification to the 
demonstration code would be required. The code would simply handle the new route of travel as a fast 
train and would process the various route schedules accordingly. Secondly, a new data parser module 
could be introduced to the demonstration code. This would require a third party programmer with 
knowledge of the demonstration code interfacing protocol to create a new module to collect the high 
speed rail information from the internet. This module would then be introduced to the demonstration 
program, at which point the router module would prompt the user that a new mode of transit is attempting 
to integrate into the system and provide instructions on where and how to modify the router module to 
accept this new transit mode. 

Another future mode of travel considered was the notion of a point to point sky taxi (Ref. 19). This 
mode of transportation would consist of an on demand fleet of high lift vehicles that would be approved 
for landing and takeoff nearly everywhere; providing the same function of a traditional taxi service but 
with superior speed and range. As with the addition of a high speed rail network, there are two methods 
with which to incorporate this new mode of travel. Whether the sky taxi mode of travel falls under one of 
the current data parser jurisdictions, or a new data parser module is required, the process is exactly the 
same. Regardless of the technical details of any new method of transportation, only the information 
relating cost, time, and emissions is required by the demonstration code to provide an optimized route for 
the user. 

Consideration of the relative safety of various modes of travel may be implemented in any future 
iteration of the demonstration program. Personal automobiles are the single most fatal mode of 
transportation for the general populous (Ref. 20). A metric of safety could be added to the current travel 
metrics of cost, time, and environmental impact to provide the user with still more options of preference 
when planning their intermodal journey. Furthermore, application of the demonstration program to 
personal mobile devices could warn travelers of upcoming danger or delay, as described in the following 
scenario. 

Once again, consider that several users of the integrated intermodal transportation system are 
traveling along similar routes, each of which directs their respective users along a particular highway. 
Additionally, several of the users are carrying personal mobile devices which are providing turn by turn 
directions. An accident occurs and a traffic jam quickly forms. The mobile device of the intermodal 
system user nearest the accident detects that the user has either stopped or fallen behind the intended 
routing schedule by monitoring their current GPS location. The intermodal system installed on the now 
delayed traveler relays to all other intermodal systems that there is a potential problem at its location and 
that consideration should be made in order to reroute other travelers around the newly formed traffic 
congestion. Additionally, the local police and news reporting agencies may have access to the integrated 
intermodal system information and may now provide the appropriate services to more quickly mitigate 
the dilemma; whether that is to dispatch law enforcement to reroute traffic or report to the general public 
about the current traffic condition. Alternatively, users who witness a traffic accident, backup, or other 
travel delay may enter the information manually to notify other intermodal systems and travelers of the 
potential setback. 
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Conclusion 


The results from the demonstration code show that using public transportation can have a huge impact 
on the amount of carbon dioxide released into the environment during each trip. Also, even with the large 
wait times that go along with them, flights can save a passenger’s time and reduce their environmental 
impact. The only metric that public transit could not overcome was that of cost, but the demonstration 
code written for this study does not explicitly include other costs associated with automobiles, such as 
parking, insurance, and any maintenance. Instead the demonstration code only considers a flat $0.5 1/mile 
expense, which may not necessarily represent every personal vehicle. Another aspect of the 
demonstration code that is important for future additions and modifications is its object oriented 
architecture. 

There are a variety of ways to improve upon the public transportation system and how to increase 
public awareness. One method is through future public transportation concepts such as sky taxi, high 
speed rail and NextGen (Refs. 12, 18, and 19). These can help to reduce congestion both on the ground 
and in the air and allow for easier transportation from start to finish. Increasing public awareness can be 
done by agencies and companies releasing their bus, train, and airline information to third party 
developers, who can then provide a variety of ways for the public to connect with public transit. 

If future companies and agencies allow for open sourced information, the only remaining challenge is 
to overcome the vast amount of dynamic data available. Future developments will only increase the 
amount of information accessible to the public. Improvements will allow for a single program or series of 
programs to be able to handle any kind of public transportation from one point to another anywhere in the 
world. The demonstration code reveals the promise of faster, cleaner, and potentially cheaper intermodal 
transportation for everyone. 


NASA/TM— 20 12-2 17286 


10 



Appendix A. — Sample Inter-City Route Output 

========== Welcome to the Integrated Intermodal System ===================== 

Please enter the following information to begin your trip: 

DestinLoc,DepartLoc,DepartDate,DepartTime, Priority (str,str,[dd,mm,yyyy],[hh,mm],str):'21st St NW 
and R St NW, Washington DC','W 109th St and Broadway, New York, NY', [5, 8, 201 l],[10,38],'eco' 


Please standby while we calculate your solution. 


Destination Lat: 38.912609 Lon: -77.046624 
Departure Lat: 40.803603 Lon: -73.9672251 
Departure date/time accepted. 


Baseline Automotive Statistics: 
Cost: 1 18.64 dollars 

Time: 16283 seconds 

Emissions: 226 pounds 


Optimum modes: Public-Plane-Public 
Cost: 151.50 dollars 

Time: 42180 seconds 

Emissions: 171 pounds 
Route: 

1. ) Head northwest on W 109th St toward Riverside Dr 

2. ) Turn right onto Riverside Dr 

3. ) Take the 1st right onto W 1 10th St Cathedral Pkwy 

4. ) Cathedral Pkwy depart at 10:38 -> Times Sq - 42 St arrive at 10:51 13 mins 

5. ) Metro | SOUTH FERRY | Route: 1 Broadway - 7 Avenue Local | Provider: MTA New York City 
Transit 

6. ) Times Sq - 42 St -> 42 St - Port Authority Bus Terminal Walk 5 mins 

7. ) 42 St - Port Authority Bus Terminal depart at 10:57 -> Euclid Av arrive at 1 1 :30 33 mins 

8. ) Metro | OZONE PARK - LEFFERTS BLVD | Route: A 8 Avenue Express | Provider: MTA New 
York City Transit 

9. ) Head south on Euclid Ave toward Pitkin Ave 

Destination will be on the right 

10. ) EUCLID AV - PITKIN AV depart at 1 1 :36 -> BROOKLYN - GENERAL P.O. arrive at 1 1 :46 
1 0 mins 

11. ) Bus | B13 SPRING CREEK GATEWAY MALL | Route: B13 CRESCENT STREET | Provider: 
MTA New York City Transit 

12. ) BROOKLYN - GENERAL P.O. depart at 1 1 :57 -> INNER TERM - STOP 4C INTL ARRIVAL 
arrive at 12:16 19 mins 

13. ) Bus | B15 JFK AIRPORT via POSTAL FAC | Route: B15 NEW LOTS AV - JFK AIRPOR | 
Provider: MTA New York City Transit 

14. ) Head northeast toward Van Wyck Expy 

15. ) Slight left 

16. ) Take the ramp 

17. ) Slight left 

Destination will be on the right 

18. ) Board flight 16546 departing at 14:29 


NASA/TM— 20 12-2 17286 


11 


19. ) Arrive at 16:0 

20. ) Dulles Airport depart at 5:50 -> SW D ST & SW 7TH ST arrive at 6:37 0 hours and 47 mins 

21. ) Head east on D St SW toward 7th St SW 
Destination will be on the left 

22. ) L'ENFANT PLAZA METRO STATION depart at 17:19 -> METRO CENTER METRO 
STATION arrive at 17:24 5 min s 

23. ) Metro | FRANCONIA METRO | Route: Blue Metrorail Blue Line | Provider: METRO 

24. ) METRO CENTER METRO STATION depart at 17:29 -> DUPONT CIRCLE METRO 
STATION arrive at 17:34 5 mins 

25. ) Metro | GROSVENOR | Route: Red Metrorail Red Line | Provider: METRO 

26. ) Head southeast on Connecticut Ave NW 

27. ) At the traffic circle, take the 1st exit onto Massachusetts Ave NW 

28. ) Turn right onto Florida Ave NW 

29. ) Sharp right onto 21st St NW 

30. ) Head east on D St SW toward 7th St SW 
Destination will be on the left 

31. ) L'ENFANT PLAZA METRO STATION depart at 10:41 -> METRO CENTER METRO 
STATION arrive at 10:46 5 mins 

32. ) Metro | VIENNA | Route: Orange Metrorail Orange Line | Provider: METRO 

33. ) METRO CENTER METRO STATION depart at 10:55 -> DUPONT CIRCLE METRO 
STATION arrive at 10:57 2 mins 

34. ) Metro | SHADY GROVE | Route: Red Metrorail Red Line | Provider: METRO 

35. ) Head southeast on Connecticut Ave NW 

36. ) At the traffic circle, take the 1st exit onto Massachusetts Ave NW 

37. ) Turn right onto Florida Ave NW 

38. ) Sharp right onto 21st St NW 
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Appendix B. — Sample Intra-City Route Output 

========== Welcome to the Integrated Intermodal System ====================== 

Please enter the following information to begin your trip: 

DestinLoc,DepartLoc,DepartDate,DepartTime, Priority (str,str,[dd,mm,yyyy],[hh,mm],str):'H St NW 
and 20th St NW, Washington DC','4th St NW and Jefferson Dr SW, Washington 
DC', [5,8,2011], [10,37], 'eco' 


Please standby while we calculate your solution. 


Destination Lat: 38.8995739 Lon: -77.0448869 
Departure Lat: 38.888793 Lon: -77.0175553 
Departure date/time accepted. 


Baseline Automotive Statistics: 
Cost: 1.16 dollars 

Time: 659 seconds 

Emissions: 2 pounds 


Optimum modes: Public 
Cost: 2.50 dollars 

Time: 1620 seconds 

Emissions: 1 pounds 
Route: 

1. ) Head south on 4th St SW toward Independence Ave SW 

2. ) Take the 3rd left onto D St SW 

Destination will be on the right 

3. ) FEDERAL CENTER METRO STATION depart at 10:45 -> FARRAGUT WEST METRO 
STATION arrive at 10:53 8 mins 

4. ) Metro | FRANCONIA METRO | Route: Blue Metrorail Blue Line | Provider: METRO 

5. ) Head south on 17th St NW toward I St NW 

6. ) Turn right onto Pennsylvania Ave NW 

7. ) Turn left onto 19th St NW 

8. ) Take the 1st right onto H St NW 

9. ) Take the 1st right onto 20th St NW 

Destination will be on the left 


NASA/TM— 20 12-2 17286 


13 


References 


1. European Metropolitan Transportation Authorities, “EMTA Barometer of Public Transport in the 
European Metropolitan Areas,” EMTA, Paris, France, Dec. 2004. 

2. U.S. Environmental Protection Agency, “Emission Facts: Greenhouse Gas Emissions from a 
Typical Passenger Vehicle,” Office of Transportation and Air Quality, EPA420-F-05-004, 
Washington, D.C., 2005. 

3. Google Transit, Beta, Google Corporation, Mountain View, California, 2011. 

4. PlymGo.com, Plymouth City Council, Plymouth, Devon, United Kingdom, 2011. 

5. Cameron, M., and Tschirren, B., Rome2Rio.com, Beta, Melbourne, Australia, Apr. 2011. 

6. Transportation Safety Administration, U.S. Department of Homeland Security, 
www.tsa.gov/travelers/airtravel/assistant/arrival.shtm, 4 Aug. 2011. 

7. U.S. General Services Administration, www.gsa.gov/portal/content/100715, 4 Aug. 2011. 

8. Jeppesen, A Boeing Company, www.jeppesen.com/land/joumey-planning/, 4 Aug. 2011. 

9. M.J. Bradley & Associates, “Comparison of Energy Use & C0 2 Emissions From Different 
Transportation Modes,” Manchester, New Hampshire, May 2007. 

10. Jeppesen, “Jeppesen Journey Planner Interface Overview - REST Protocol,” Perth, Australia, Jun. 
2011 . 

11. Edwards, T., British Broadcasting Corporation, “Public transport in London: A decade in numbers,” 
BBC News London, www.bbc.co.uk/blogs/mindthegap/201 1/0 l/public_transport 
_in_london_a_d.html, 4 Aug. 2011. 

12. Federal Aviation Administration, “FAA’s NextGen Implementation Plan,” U.S. Department of 
Transportation, Mar. 2011. 

13. Boeing Management Company, “Current Market Outlook 2011-2030,” Boeing, Jun. 2011. 

14. Leahy, J., “Airbus Global Market Forecast 2010-2029,” Airbus, Toulouse, France, 13 Dec. 2010. 

15. Federal Aviation Administration, “FAA Aerospace Forecast Fiscal Years 2011-2031,” U.S. 
Department of Transportation, Apr. 2011. 

16. Chemoff, M., “Where’s my bus? Open data enables real-time route info for Boston riders,” 
OpenSource.com, Red Hat Inc., opensource.com/govemment/10/6/wheres-my-bus-open-data- 
enables-real-time-route-info-boston-riders, 3 Jun. 2010. 

17. Transport for London, United Kingdom Government, www.tfl.gov.uk, 4 Aug. 2011. 

18. U.S. High Speed Rail Association, “US High Speed Rail Network Map,” US HSR, 
www.ushsr.com/ushsrmap.html, 10 Aug. 2011. 

19. BlueSkyTaxi.com, BlueSky Taxi, Inc. blueskytaxi.com, 10 Aug. 2011. 

20. Halperin. K., “A Comparative Analysis of Six Methods for Calculating Travel Fatality Risk,” 
Fra nk lin Pierce Law Center, law.unh.edu/risk/winter/halperin.htm, 10 Aug. 2011. 


NASA/TM— 20 12-2 17286 


14 



REPORT DOCUMENTATION PAGE 


Form Approved 
OMB No. 0704-0188 


The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the 
data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this 
burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. 
Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB 
control number. 

PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 


1. REPORT DATE (DD-MM-YYYY) 
01-03-2012 


2. REPORT TYPE 

Technical Memorandum 


4. TITLE AND SUBTITLE 

Integrated Intermodal Passenger Transportation System 


6. AUTHOR(S) 

Klock, Ryan; Owens, David; Schwartz, Henry; Plencner, Robert 


3. DATES COVERED (From - To) 


5a. CONTRACT NUMBER 


5b. GRANT NUMBER 


5c. PROGRAM ELEMENT NUMBER 


5d. PROJECT NUMBER 


5e. TASK NUMBER 


7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 

National Aeronautics and Space Administration 
John H. Glenn Research Center at Lewis Field 
Cleveland, Ohio 44135-3191 


5f. WORK UNIT NUMBER 

WBS 561581.02.08.03.11.01 


8. PERFORMING ORGANIZATION 
REPORT NUMBER 

E- 18041 


9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORING/MONITOR'S 

National Aeronautics and Space Administration ACRONYM(S) 

Washington, DC 20546-0001 NASA 

11. SPONSORING/MONITORING 
REPORT NUMBER 

NASA/TM-2012-2 17286 


12. DISTRIBUTION/AVAILABILITY STATEMENT 

Unclassified-Unlimited 

Subject Categories: 85 and 03 

Available electronically at http://www.sti.nasa.gov 

This publication is available from the NASA Center for AeroSpace Information, 443-757-5802 


13. SUPPLEMENTARY NOTES 

Ryan Klock, University of Michigan; David Owens, Virginia Polytechnic Institute and State University; and Henry Schwartz, Georgia 
Institute of Technology, summer interns. 


14. ABSTRACT 

Modem transportation consists of many unique modes of travel. Each of these modes and their respective industries has evolved 
independently over time, forming a largely incoherent and inefficient overall transportation system. Travelers today are forced to spend 
unnecessary time and efforts planning a trip through varying modes of travel each with their own scheduling, pricing, and services; causing 
many travelers to simply rely on their relatively inefficient and expensive personal automobile. This paper presents a demonstration program 
system to not only collect and format many different sources of trip planning information, but also combine these independent modes of 
travel in order to form optimal routes and itineraries of travel. The results of this system show a mean decrease in inter-city travel time of 10 
percent and a 25 percent reduction in carbon dioxide emissions over personal automobiles. Additionally, a 55 percent reduction in carbon 
dioxide emissions is observed for intra-city travel. A conclusion is that current resources are available, if somewhat hidden, to drastically 
improve point to point transportation in terms of time spent traveling, the cost of travel, and the ecological impact of a trip. Finally, future 
concepts are considered which could dramatically improve the interoperability and efficiency of the transportation infrastructure. 


15. SUBJECT TERMS 

Transportation; Transportation networks; Air transportation; Urban transportation; Information systems; Traffic; Costs; Carbon 
dioxide; Interoperability; Economic impact; Efficiency; Routes 


16. SECURITY CLASSIFICATION OF: 


a. REPORT 

u 


b. ABSTRACT 

u 


c. THIS 
PAGE 

u 


17. LIMITATION OF 

18. NUMBER 

ABSTRACT 

OF 


PAGES 

uu 

20 


19a. NAME OF RESPONSIBLE PERSON 

STI Help Desk (email:help@sti.nasa.gov) 


19b. TELEPHONE NUMBER (include area code) 

443-757-5802 


Standard Form 298 (Rev. 8-98) 
Prescribed by ANSI Std. Z39-18 



































